在訂單成立以及建立金流部份，因為情境非常多，
因此在製定狀態的部份其實也是有很多可以討論的，
還記得在最一開始--Day13 訂單 -- 基礎結構的部份，
我們order.status定義為unpaid、paid、failed三種，
但到後面--Day21 訂單金流 -- 獨立資料的時候，
order.status定義已經變成了processing、finished、refund、cancel、error這幾種，
原本的unpaid、paid、failed改由payment.status做紀錄，
除了以上幾種之外還有很多中繼狀態點，主要功能用於卡點以及debug，
在串接金物流或者上線的時候，常常會發生很多意料之外的事情，
也因為因為串接為兩邊資料丟來丟去，很容易遇到找不到是哪邊的問題，
因此我們多設定一些中繼狀態點，可以幫助我們快速找到出現錯誤的地方，
從上圖可以看到我們的定了很多狀態，當然這邊還不包含物流，
主要方向在於可以透過狀態快速找到斷點，這邊只列出個人覺得比較重要的卡點，
流程以及不足的地方都可以自行可製化調整，這邊只是範例。
iThome鐵人賽
看影片追技術